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Brief mailed December 10, 2007. Permission is hereby granted to 
charge or credit deposit account number 14-0620 for any errors in 
fee calculation. Appellants request this Appeal Brief be made of 
record and fully considered. 

REAL PARTY IN INTEREST 

The Real Party in interest is: 
Unisys Corporation 

Township Line and Union Meeting Roads 

Blue Bell, Pennsylvania 19424 
being the assignee of the entire right, title, and interest by all 
inventors, by way of assignment documents filed at Reel 015754, 
frame 0722, in the United States Patent and Trademark Office. 

RELATED APPEALS AND INTERFERENCES 

There are no known pending Appeals and/or Interferences which 
will directly affect or be directly affected by or have a bearing 
on the Board's decision in this appeal. Therefore, there are no 
decisions to be placed in the attached Related Proceedings 
Appendix. 
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STATUS OF CLAIMS 



The subject patent application was filed on May 19, 2004 
containing claims 1-21. On November 30, 2006, the Examiner mailed 
an initial official action rejecting all pending claims. In 
accordance with the amendment filed February 27, 2007, claims 1, 7, 
11, 12, 17, and 21 were amended. On May 31, 2007, the Examiner 
mailed a Final Office Action finally rejecting all pending claims. 
Applicants appeal from that final rejection and have not filed an 
amendment after final. Therefore, appealed claims 1-21, being all 
pending claims, stand finally rejected and are presented in the 
Claims Appendix, hereto attached, in the form following entry of 
the amendment filed February 27, 2007. No pending claim has ever 
been found to contain allowable subject matter. 

There remains a provisional obviousness-type double patenting 
rejection, which is not yet ripe. Applicants will deal with this 
issue by way of terminal disclaimer or other appropriate measure 
after the matter becomes ripe. . 



STATUS OF THE AMENDMENTS 



The amendment filed February 27 , 2007 was entered as a matter 
of right. No amendment after final under 37 C.F.R. 1.116 was filed 
in response to the final office action mailed May 31, 2007. 
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SUMMARY OF CLAIMED SUBJECT MATTER 1 

The present invention generally relates to legacy data base 
management systems and more particularly relates to enhancements 
for providing JavaScript access to multiple dataset comparison 
functions offered by such legacy data base management systems 2 . 
Such commercial systems have ben in general use for more than 20 
years. One of the most successful data base management systems is 
available from Unisys Corporation and is called the Classic MAPPER® 
data base management system 3 . 

In order to permit any such access, the present invention must 
first provide a user interface, called a gateway, which translates 
transaction data transferred from the user over the Internet in 
HTML format into a format from which data base management system 
commands and inputs may be generated 4 . To make access to a 
proprietary legacy data base by Internet users practical, a 
sophisticated security system is required to prevent intentional or 
inadvertent unauthorized access to the sensitive data of an 
organization 5 . 



1 The references to the specification and drawings provided herein are only exemplary and are not deemed to be 

limiting. The purpose of the references is to enable the Board to more quickly determine where the claimed subject 

matter is described within the present application. 

2 See Specification at page 1, line 21, through page 2, line 2. 

3 See Specification at page 2, lines 3-5. 

4 See Specification at page 6, lines 5-8. 

5 See Specification at page 6, lines 13-15. 
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In accordance with the preferred mode of the present 
invention, the user can access the underlying MAPPER data 
manipulation capabilities in a JavaScript object-based programming 
environment. Therefore programmers knowledgeable in the practices 
of standard programming languages such as JavaScript can readily 
apply those skills to utilize the data manipulation and other 
capabilities derived from the underlying MAPPER engine. Each 
JavaScript represents a stored procedure of varying degrees of 
complexity that can be called from various development and 
application software within the DACS BISNET product suite 6 . 

In the preferred implementation, the JavaScript parser and 
objects are integrated into the MAPPER engine to support JavaScript 
stored procedures. The integrated JavaScript parser interprets and 
executes JavaScript stored procedures, which utilize custom 
JavaScript objects. These custom capabilities are in an object- 
based, paradigm for dataset manipulation and analysis purposes. 
Additional custom JavaScript objects are also provided to support 
the more complex MAPPER core engine "power" function analysis 
capabilities. JavaScript stored procedures are an alternative to 
MAPPER run-script; input and output arguments can be passed, and a 
resulting dataset can be returned to the caller 7 . 

A key to making this process efficient is the technique for 
"parameterization" of the underlying MAPPER "power" commands. In 

6 See Specification at page 10, lines 1-7. 
7 See Specification at page 10, lines 9-16. 



order to leverage the more complex MAPPER core engine "power" 
function analysis capabilities, it is necessary for the programmer 
to supply a set of arguments. The arguments are positional and the 
number can range from just a few to many dozens. As the number of 
arguments increases, the burden of programming them can become 
unmanageable 8 . 

As originally conceived, the MAPPER engine power functions 
were invoked via the procedural BIS script language. This 
interface is satisfactory for programming simple sets of arguments, 
although it has the inherent disadvantage of requiring intricate 
knowledge of the proprietary BIS script language syntax. This 
syntax is very efficient, but at the tradeoff of being cryptic and 
therefore error prone and requiring specialized training. As the 
number of arguments increases, the programming task becomes 
daunting 9 . 

To compliment the JavaScript Dataset object, which represents 
a physical MAPPER database table, a suite of Parameter objects is 
provided to allow programming the numerous combinations of 
arguments that parameterize the processing performed by MAPPER core 
engine power function analysis functions. A separate JavaScript 
Parameter object is provided for each of the MAPPER core engine 
power functions. Each Parameter object contains custom properties, 



8 See Specification at page 10, lines 17-22. 
9 See Specification at page 1 1, lines 1-6. 
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methods, and compound objects that conform to the programming 
requirements of a specific power function 10 . 

The system of the preferred mode provides a method and 
apparatus for comparing information across multiple datasets in a 
Javascript environment. The Dataset compareDatasets ( ) power 
function searches two dataset columns that match the specified 
compare item criteria. This function performs a character-to- 
character comparison of specified columns in the two datasets. 
This means that an application programmer can utilize the 
compareDatasets ( ) power functions' s capabilities provided by the 
MAPPER engine in terms of a standardized object-based programming 
language such as JavaScript to compare information from two 
different datasets. Previously, this MAPPER power function was 
only available using the proprietary MAPPER run script procedural 
language . 11 

Fig. 1 is a pictorial diagram of hardware suite 10 of the 
preferred embodiment of the present invention 12 . Fig. 2 is a 
detailed flow diagram showing integration of JavaScript with the 
MAPPER engine 13 . Fig. 15 shows the contents of the target and 
issuing datasets and the location of the first non-matching 
occurrence. To find the next non-matching occurrence for the above 
example, the oComp. resume property is changed to "rsmNextltem" or 

I0 See Specification at page 11, lines 7-13. 
11 See Specification at page 11, lines 14-22. 
12 See Specification at page 14, lines 10-11. 
I3 See Specification at page 16, lines 2-3. 
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"rsmNextRecord" . Another request is then issued in the form of 
c, oDs . compareDatasets (....) request$ . 14 

Claim 11 is the only pending claim introducing "means-plus- 
function" limitations. Independent claim 11 has four such 
limitations which are correlated to Applicants 1 disclosure as 
follows : 

a. "storing means for storing a plurality of datasets within 

a legacy data base 15 "; 

b. "requesting means responsively coupled to said storing 
means for requesting a comparison of said plurality of 
datasets via a standardized command language 16 "; 

c. "converting means responsively coupled to said storing 
means for converting said standardized command language 
into a legacy command language suitable to access said 
legacy data base" 17 ; and 

d. "preparing means responsively coupled to said storing 
means for preparing a comparison result 18 ". 



In accordance with the Notification of Non-Compliant Appeal 
Brief mailed December 10, 2007, Applicants herewith endeavor to map 



14 See Specification at page 31, lines 2-5. 

15 See Fig. 1, elements 20 and 22, and specification at page 14, lines 16-17. 
16 See Fig. 1, element 12, and specification at page 14, lines 11-15. 
17 See Fig. 2, element 38, and specification at page 16, lines 3-5. 
18 See Fig. 14 and specification at page 30. 
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claims 1, 6, 16, and 21 to "the specification by page and line 
number, paragraph number, and to the drawings, if any". 
Claim 1: 

element a — see Fig. 1, elements 20 and 22, and specification 

at page 15, lines 16-17; 

element b -- see Fig. 1, element 12, and specification at page 

14, lines 11-15; 

element c — see Fig. 2, element 38 and specification at page 

17, lines 3-5; and 

element d — see Fig. 14 and specification at page 20. 

Claim 6: 

element a — see Fig. 1, element 12, and specification at page 

14, lines 11-15; 

element b — see Fig. 1, elements 20 and 22, and specification 

at page 14, lines 16-17; 

element c — see Fig. 2, element 38, and specification at page 

16, lines 3-5; 

element d — see Fig. 14 and specification at page 30; 

element e — see Fig. 14 and specification at page 30. 

Claim 16: 

element a — see Fig. 1, elements 20 and 22, and specification 

at page 14, lines 16-17; 

element b — see Fig. 2, element 38, and specification at page 

16, lines 3-5; 
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element c — see Fig, 14 and specification at page 30. 

Claim 21: 

element a — see Fig. 1, elements 20 and 22, and specification 

at page 14, lines 16-17; 

element b -- see Fig. 1, element 12, and specification at page 

14, lines 11-15; 

element c — see Fig. 2, element 38 and specification at page 

16, lines 3-5; 

element d — see Fig. 14 and specification at page 30; and 

element e — see Fig. 14 and specification at page 30. 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



1. Are the drawings objectionable under 37 C.F.R. 1.83(a)? 

2. Are claims 1-5 and 21 unpatentable under 35 U.S.C. 102(e) 
as anticipated by U.S. Patent Application Publication No. 
2005/0192851, published in the name of Rangnekar (hereinafter 
referred to as "Rangnekar")? 

3. Are claims 6-13, and 16-21 unpatentable under 35 U.S.C. 
102(e) as anticipated by U.S. Patent Application Publication No. 
2004/0226027, published in the name of Winter (hereinafter referred 
to as "Winter")? 

4. Are claims 6-20 unpatentable under 35 U.S.C. 102(b) as 
anticipated by U . S . Patent Application Publication No . 2003/0051070 , 
published in the name of Shappir et al. (hereinafter referred to as 
"Shappir")? 
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5. Are claims 14-15 unpatentable under 35 U.S.C. 103(a) as 
obvious over Winter in view of Applicant Admitted Prior Art 
(hereinafter referred to as "AAPA" ) ? 
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ARGUMENT 



I. The drawings are not objectionable under 37 C.F.R. 1.83(a). 

The Examiner has objected to the drawings under 37 C.F.R. 
1.83(a). Specifically, he is concerned with his inability to find 
the claimed "legacy data base management system" and "facility which 
parses" within the drawings. 

As to the claimed "legacy data base management system" , in the 
preferred mode, the functionality is based upon use of the Classic 
MAPPER legacy data base management system discussed in the 
specification at page 2, lines 1-7, of the specification. As 
explained at page 11, the MAPPER system is preferably incorporated 
into the BIS/Cool ICE system. Page 14, lines 4-9, discusses how the 
MAPPER legacy data base management system is made commercially 
available within the BIS/Cool ICE environment. The hardware suite 
includes elements 20 and 22 of Fig. 1 as explained at page 14, lines 
16-17. Thus, the claimed "legacy data base management system" is 
located within Fig. 1, elements 20 and 22. Various functional 
components of the MAPPER legacy data base management system are 
shown in Fig. 2. Thus, it is deemed that Applicants 1 drawings 
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adequately show the claimed "legacy data base management system" in 
compliance with 37 C.F.R. 1.83(a). 

The claimed "facility which parses" is functionally discussed 
throughout the specification. A representation is shown 

functionally in Fig. 2. Therefore, Applicants deem that the claimed 
"facility which parses" is adequately shown in accordance with the 
requirements of 37 C.F.R. 1.83(a). 

II. Claims 1-5 and 21 are not anticipated by Rangnekar. 

Claims 1-5 and 21 have been rejected under 35 U.S.C. 102(e) as 
being anticipated by U.S. Patent Application No. 2005/0192851, 
published in the name of Rangnekar (hereinafter referred to as 
"Rangnekar") . The ground of rejection should be reversed as to the 
rejected claims for the following reasons. 

The standards for a finding of anticipation during examination 

are specified in MPEP 2131, which provides in part: 

TO ANTICIPATE A CLAIM, THE REFERENCE MUST TEACH 
EVERY ELEMENT OF THE CLAIM 
"A claim is anticipated only if each and every element as set 
forth in the claim is found, either expressly or inherently 
described, in a single prior art reference." Verdegaal Bros, 
v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 
1051, 1053 (Fed. Cir. 1987). " The identical invention must be 
shown in as complete detail as is contained in the . . . claim. " 
Richardson v. Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ2d 
1913, 1920 (Fed. Cir. 1989). (emphasis added) 

The rejection should be reversed because "the identical invention" 

is not shown by Rangnekar "in as complete detail as is contained in 

the claims" as is required by MPEP 2131. 
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Applicants' invention as disclosed and claimed provides a 
method and apparatus for comparing heterogeneous , incompatible 
datasets from a user terminal via a legacy data base management 
system. This is accomplished by using the legacy data base 
management system to map data elements from the heterogeneous, 
incompatible data bases into a format which it can readily 
accommodate using the computational capacity of the legacy data 
base management system to perform the necessary conversions. 

For whatever reason, the Examiner has cited and sought to 
apply Rangnekar, which is concerned with booking travel 
arrangements from an Automatic Teller Machine (ATM) . Thus, instead 
of a user accessing data from a general purpose data base 
management system as claimed, Rangnekar is limited to sending 
minimal information via a non-alphanumeric ATM. As a result of the 
lack of pertinence of this reference, the rejection of claims can 
only be based upon clearly erroneous findings of fact and incorrect 
application of controlling law. Key to this process is that the 
Examiner impermissibly ignores Applicants' invention as claimed in 
an attempt to show that non-pertinent elements from Rangnekar are 
related to Applicants' claimed limitations. This is impermissible, 
because controlling law does not permit the Examiner to redefine 
Applicants 1 claims to fit his grounds of rejection. 

II. A. Claim 1 is not anticipated by Rangnekar. 
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1 « 

Claim 1, for example, has four basic elements. The first 
claimed element is "a legacy data base management system having a 
first command language and having a plurality of datasets". In 
making his rejection, the Examiner cites Rangnekar, paragraph 142, 
apparently alleging that CRS 30 is the claimed element. However, 
there is no mention in the citation (or elsewhere) that CRS has "a 
first command language" or a "plurality of datasets" as claimed. 
Therefore, the Examiner simply ignores these limitations. 

The second element is "a user terminal which generates a 
request in a standardized command language for comparing some of 
said plurality of datasets within said legacy data base". Instead 
of addressing this element, the Examiner impermissibly "redefines" 
the claimed element as a "user session " . He then alleges that 
Rangnekar, element 12, is an "end user" and that this "end user" is 
somehow the "user session " which is not actually claimed by 
Applicants. As a result, his findings are contrary to law, clearly 
erroneous, unsupported by the reference, and legally irrelevant as 
unrelated to Applicants 1 claimed element. The remainder of his 
analysis is largely incomprehensible. 

The third claimed element, as amended, is "a facility located 
within said legacy data base management system which parses said 
request in said standardized command language into a corresponding 
request in said first command language". Having found that the 
claimed "legacy data base management system" is shown as CRS 30 in 
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Rangnekar, the Examiner ignores his own previous finding and 
Applicants' claimed invention. He cites numerous paragraphs and 
figures of Rangnekar to show "parsing" and "conversion" by 
virtually every portion of Rangnekar except CRS 30. 

The fourth claimed element is "a result produced by said 
legacy data base management system indicative of honoring said 
corresponding request''. The claimed "result" must be produced by 
said legacy data base management system . Nevertheless, the 
Examiner cites quantities produced by host system 20 and web server 
24 , He does not even allege the claimed "result 7 ' as " produced by 
said legacy data base management system " . 

As a result of Rangnekar having none of the four claimed 
elements of claim 1, the rejection of claim 1, and all claims 
depending therefrom, should be reversed for failure to comply with 
MPEP 2131. 

II. B. Claim 2 is not anticipated by Rangnekar. 

Claim 2 depends from claim 1 and further limits the claimed 
"first command language". Completely ignoring the claim, the 
Examiner finds that Rangnekar discloses "a JavaScript object". 
This finding, even if supported by the reference (which it is not), 
is legally irrelevant, because it does not address the claimed 
"first command language". This is incorrect as a matter of law. 
The rejection of claim 2 should be reversed. 
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II. C. Claim 3 is not anticipated by Rangnekar. 

Claim 3 depends from claim 2 and further limits the claimed 
"result". Completely ignoring the claim, the Examiner finds that 
Rangnekar discloses "a JavaScript object". This finding, even if 
supported by the reference (which it is not) , is legally 
irrelevant, because it does not address the claimed "result". This 
is incorrect as a matter of law. The rejection of claim 3 should 
be reversed. 

II. D. Claim 4 is not anticipated by Rangnekar. 

Claim 4 depends from claim 3 and further limits the claimed 

coupling network. In making his rejection, the Examiner makes 

several unrelated citations in an apparent attempt to contradict 

the clear teaching of Rangnekar. Paragraph 111 of Rangnekar 

explicitly states : 

As illustrated in FIG. 14, financial institutions run 
their ATM' s 12 on their private networks. (Emphasis 
added) 

It is not understood why the Examiner would ignore the clear 
teaching of his own reference (i.e., private ) to "interpret" the 
opposite structure (i.e., public ) . The rejection of claim 4 should 
be reversed. 
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II. E. Claim 5 is not anticipated by Rangnekar. 

Claim 5 depends from claim 4 and is further limited by 
"wherein said data base management system further comprises a data 
base having a plurality of columns of data wherein each of said 
plurality of datasets corresponds to a different one of said 
plurality of columns of data''. Because the Examiner is aware that 
Rangnekar cannot meet these limitations, the Examiner cites 
paragraph 0204, which he knows does not even mention "columns". 
The rejection of claim 5 should be reversed. 

II. F. Claim 21 is not anticipated by Rangnekar. 

Notwithstanding the differences in claimed limitations 19 
between claims 1 and 21, the Examiner apparently has not felt the 
need to actually examine claim 21 as required by controlling law. 
Therefore, the rejection of 21 should be reversed for failure of 
the Examiner to examine it. 

III. Claims 6-13, and 16-21 are not anticipated by Winter. 

Claims 6-13 and 16-21 have been rejected under 35 U.S.C. 
102(e) as being anticipated by U.S. Patent Publication 
2004/0226027, published in the name of Winter (hereinafter referred 
to as "Winter") . This rejection should be reversed because "the 



19 See for example limitations of the specific command language, the coupling network, the columnar structure of the 
datasets, etc. 
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identical invention" is not shown by Winter "in as complete detail 
as is contained in the claims" as is required by MPEP 2131. 

The present invention provides an apparatus for and method of 
utilizing JavaScript to request a complex comparison from a legacy 
data base management system. The user is thus able to evoke the 
powerful dataset comparison tools of the legacy data base 
management system. This approach leverages the power of the legacy 
data base management without the need for the user to become 
familiar with the proprietary command language of the legacy data 
base management system. The approach is particularly efficient in 
that the user can provide parameters directly to the legacy data 
base management system as a parameter object defined within the 
standardized object-based command language. 

Winter on the other hand, discusses a method of separating a 
function of the business logic of an application from a user 
interface of the application where the business logic and user 
interface of the application are intermingled. The method 
includes providing a wrapper interface for the application. The 
method also includes providing a function of the business logic of 
the application separated from the user interface of the 
application through the wrapper interface. 

The differences in these approaches are readily apparent in 
structure and operation. Winter relies upon completely "wrapping" 
a legacy system such that all external communication to and from 
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the legacy system must be converted before being delivered to the 
intended recipient (see Fig. 1, element 104) . Thus, the approach 
tends to be less efficient than Applicants' technique which does 
not require a wrapper for complete conversion of all 
communications. For example, in Applicants' system, the claimed 
"facility for parsing" is located in the claimed legacy data base 
management system without any conversion required. In other words, 
the claimed legacy data base management system performs the 
necessary conversions by "parsing" the JavaScript command language 
service request. These differences in approach manifest themselves 
in structural and functional differences which are best observed in 
view of analysis of the individual claims. 

III. A. Claim 6 is not anticipated by Winter. 

Claim 6, for example, is an independent method claim having 
five basic steps as limiting elements. The first claimed element 
is "generating a comparison request in a standardized command 
language". Because Winter does not have the claimed "comparison 
request", the ignores Applicants 1 claimed invention and 
irrelevantly alleges that Winter "generates a request". 

The second element, as amended, is "transferring said request 
to said legacy data base management system". Again, the Examiner 
ignores the actual claimed step, because Winter does not disclose 
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this limitation. Winter requires conversion before transferring to 
the legacy data base management system. 

The third claimed element is "converting said comparison 
request from said standardized command language into a legacy 
command language suitable for execution by said legacy data base 
management system''. Because Winter does not have the second claimed 
step, the Examiner ignores that any conversion which takes place , 
is required to occur within the claimed "legacy data base 
management system" . 

The fourth claimed element is "honoring said comparison 
request". Again, the Examiner simply ignores this claimed element, 
because it is not found in Winter. 

The fifth claimed element is "sending a result indicative of 
said honoring step" . Because Winter does not have The fourth 
claimed step, The Examiner seeks to meet this limitation by citing 
a display screen. 

As a result of Winter having none of The five claimed elements 
of claim 6, The rejection of claim 6, and all claims depending 
therefrom, should be reversed. 

III.B. Claim 7 is not anticipated by Winter. 

Claim 7 depends from claim 6 and further limits The claimed 
service request and corresponding claimed result. In making his 
rejection, The Examiner irrelevantly cites paragraphs 0030, 0041, 
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and 0059, none of which showing, mentioning, or teaching any 
service request or result as claimed. The rejection of claim 7 
should be reversed. 

III.C. Claim 8 is not anticipated by Winter. 

Claim 8 depends from claim 7 and further limits The network 
coupling The major hardware components. In making his rejection, 
The Examiner cites paragraph 0051 and Fig. 3, neither of which 
showing, mentioning, or teaching any particular coupling network. 
The rejection of claim 8 should be reversed. 

III.D. Claim 9 is not anticipated by Winter. 

Claim 9 depends from claim 8 and further limits The claimed 
service request and corresponding claimed result. In making his 
rejection, The Examiner irrelevantly cites paragraphs 0030, 0041, 
and 0059, none of which showing, mentioning, or teaching any 
service request or result as claimed. The rejection of claim 9 
should be reversed. 

III.E. Claim 10 is not anticipated by Winter. 

Claim 10 depends from claim 9 and further limits The network 
coupling The major hardware components. In making his rejection, 
The Examiner cites paragraph 0051 and Fig. 3, neither of which 
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showing, mentioning, or teaching any particular coupling network. 
The rejection of claim 10 should be reversed. 

III. P. Claim 11 is not anticipated by Winter. 

Claim 11 is an independent apparatus claim having four "means- 
plus-function" limitations. As such, The Examiner is obligated to 
examine claim 11 in accordance with MPEP 2181-2184. It is clear 
that he has not done so. Furthermore, notwithstanding The 
differences in claimed limitations between claims 6 and 11, The 
Examiner apparently has not actually examined claim 11 as required 
by controlling law. Therefore, The rejection of claim 11, and all 
claims depending therefrom, should be reversed for failure of The 
Examiner to examine it. 

Ill ,6. Claim 12 is not anticipated by Winter. 

Claim 12 depends from claim 11 and further limits The claimed 
service request and corresponding claimed result. In making his 
rejection, The Examiner irrelevantly cites paragraphs 0030, 0041, 
and 0059, none of which showing, mentioning, or teaching any 
service request or result as claimed. The rejection of claim 12 
should be reversed. 

III.H. Claim 13 is not anticipated by Winter. 
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Claim 13 depends from claim 12 and further limits The network 
coupling The major hardware components. In making his rejection, 
The Examiner cites paragraph 0051 and Fig. 3, neither of which 
showing, mentioning, or teaching any particular coupling network. 
The rejection of claim 13 should be reversed. 

III. I. Claim 16 is not anticipated by Winter. 

Claim 16 is an independent Jepson-type apparatus claim having 
two improvement elements. Notwithstanding The differences in 
claimed limitations between claims 6 and 16, The Examiner 
apparently has not actually examined claim 16 as required by 
controlling law. Therefore, The rejection of claim 16, and all 
claims depending therefrom, should be reversed for failure to be 
examined. 

111. J. Claim 17 is not anticipated by Winter. 

Claim 17 depends from claim 16 and further limits The claimed 
service request and corresponding claimed result. In making his 
rejection, The Examiner irrelevantly cites paragraphs 0030, 0041, 
and 0059, none of which showing, mentioning, or teaching any 
service request or result as claimed. The rejection of claim 17 
should be reversed. 

III.K. Claim 18 is not anticipated by Winter. 
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Claim 18 depends from claim 17 and further limits The network 
coupling The major hardware components. In making his rejection, 
The Examiner cites paragraph 0051 and Fig. 3, neither of which 
showing, mentioning, or teaching any particular coupling network. 
The rejection of claim 18 should be reversed. 

III.L. Claim 19 is not anticipated by Winter. 

Claim 19 depends from claim 18 and further limits The claimed 
service request and corresponding claimed result. In making his 
rejection, The Examiner irrelevantly cites paragraphs 0030, 0041, 
and 0059, none of which showing, mentioning, or teaching any 
service request or result as claimed. The rejection of claim 19 
should be reversed. 

III.M. Claim 20 is not anticipated by Winter. 

Claim 20 depends from claim 19 and further limits The claimed 
service request and corresponding claimed result. In making his 
rejection, The Examiner irrelevantly cites paragraphs 0030, 0041, 
and 0059, none of which showing, mentioning, or teaching any 
service request or result as claimed. The rejection of claim 20 
should be reversed. 

IV. Claims 6-20 are not anticipated by Shappir. 

Claims 6-20 have been rejected under 35 U.S.C. 102(b) as being 

anticipated by U.S. Patent Publication 2003/0051070, published in 
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The name of Shappir et al (hereinafter referred to as "Shappir") . 
This ground of rejection should be reversed for failure of Shappir 
to meet The requirements of MPEP 2131. 

Unlike Applicants' invention as disclosed and claimed, Shappir 
discusses a technique for completely separating The functions of 
The legacy data base management system from The user interface. 
Shappir accomplishes this by interposing a server between The user 
and The data base management system which emulates a legacy user 
terminal to The legacy data base management system. 

The differences in these approaches are readily apparent in 
structure and operation. Shappir permits The legacy data base 
management system to be completely unmodified. However, Shappir 
requires another server in which to store The logic for and execute 
The emulation logic. 

Applicants' approach, on The other hand, requires minor 
additions to The legacy data base management system, but does not 
require a separate server for The interface of The "service 
requests". Furthermore, The full power of The legacy data base 
management system becomes available to implement The conversion 
process . 

IV. A. Claim 6 is not anticipated by Shappir. 

Claim 6, for example, is an independent method claim having 
five basic steps as limiting elements. The second claimed step is 
"transferring said request to said legacy data base management 
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system". This transferring step does not occur in Shappir, because 
conversion must be performed before transfer to The legacy data 
base management system. 

Thus, The third step, "converting said comparison request from 
said standardized command language into a legacy command language 
suitable for execution by said legacy data base management system" 
cannot occur in within The legacy data base management system, but 
is perform in The "emulation server". As a result of Shappir not 
having at least The second and third claimed elements of claim 6, 
The rejection of claim 6, and all claims depending therefrom, 
should be reversed. 

IV. B. Claim 7 is not anticipated by Shappir. 

Claim 7 depends from claim 6 and is further limited by 
"wherein said standardized command language further comprises a 
language which is capable of producing a JavaScript object". 
Because Shappir does not disclose this limitation, The Examiner 
simply ignores it. The rejection of claim 7 should be reversed. 

IV. C. Claim 8 is not anticipated by Shappir. 

Claim 8 depends from claim 7 and is further limited by 
"wherein said generating step is performed by a user terminal". 
Because Shappir does not disclose this limitation, The Examiner 
simply ignores it. The rejection of claim 8 should be reversed. 
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IV. D. Claim 9 is not anticipated by Shappir. 

Claim 9 depends from claim 8 and is further limited by 
"wherein said result further comprises a JavaScript object". 
Because Shappir does not disclose this limitation, The Examiner 
simply ignores it. The rejection of claim 9 should be reversed. 

IV. E. Claim 10 is not anticipated by Shappir. 

Claim 10 depends from claim 9 and is further limited by 
"wherein said transferring step occurs via a publically accessible 
digital data communication network". Because Shappir does not 
disclose this limitation, The Examiner simply ignores it. The 
rejection of claim 10 should be reversed. 

IV. F. Claim 11 is not anticipated by Shappir. 

Claim 11 is an independent apparatus claim having four "means- 
plus-function" limitations. As such, The Examiner is obligated to 
examine claim 11 in accordance with MPEP 2181-2184. It is clear 
that he has not done so. Furthermore, notwithstanding The 
differences in claimed limitations between claims 6 and 11, The 
Examiner apparently has not actually examined claim 11 as required 
by controlling law. Therefore, The rejection of claim 11, and all 
claims depending therefrom, should be reversed for failure of The 
Examiner to examine it. 

IV. G. Claim 12 is not anticipated by Shappir. 
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Claim 12 depends from claim 11 and is further limited by 
"wherein said standardized command language further comprises a 
language which is capable of describing a JavaScript object". 
Because Shappir does not disclose this limitation, The Examiner 
simply ignores it. The rejection of claim 12 should be reversed. 

IV. H. Claim 13 is not anticipated by Shappir. 

Claim 13 depends from claim 12 and is further limited by "a 
publically accessible digital data communication network which 
couples said requesting means to said storing means". Because 
Shappir does not disclose this limitation, The Examiner simply 
ignores it. The rejection of claim 13 should be reversed. 

IV. I. Claim 14 is not anticipated by Shappir. 

Claim 14 depends from claim 13 and is further limited by 
"wherein said storing means further comprises MAPPER data base 
management system". Because Shappir does not disclose this 
limitation, The Examiner simply ignores it. The rejection of claim 
14 should be reversed. 

IV. J. Claim 15 is not anticipated by Shappir. 

Claim 15 depends from claim 14 and is further limited by 
"wherein said requesting means further comprises an industry 
standard personal computer". Because Shappir does not disclose 
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this limitation, The Examiner simply ignores it. The rejection of 
claim 15 should be reversed. 

IV. K. Claim 16 is not anticipated by Shappir. 

Claim 16 is an independent Jepson-type apparatus claim having 
two improvement elements. Notwithstanding The differences in 
claimed limitations between claims 6 and 16, The Examiner 
apparently has not actually examined claim 16 as required by 
controlling law. Therefore, The rejection of claim 16, and all 
claims depending therefrom, should be reversed for failure to be 
examined. 

IV. L. Claim 17 is not anticipated by Shappir. 

Claim 17 depends from claim 16 and is further limited by 
"wherein said standardized command language further comprises a 
language which describes a JavaScript object". Because Shappir 
does not disclose this limitation, The Examiner simply ignores it. 
The rejection of claim 17 should be reversed. 

IV. M. Claim 18 is not anticipated by Shappir. 

claim 18 depends from claim 17 and is further limited by 

"wherein said link further comprises a publically accessible 

digital data communication network". Because Shappir does not 

disclose this limitation, The Examiner simply ignores it. The 

rejection of claim 18 should be reversed. 
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IV. N. Claim 19 is not anticipated by Shappir. 

Claim 19 depends from claim 18 and is further limited by 
"wherein said request further comprises a JavaScript object". 
Because Shappir does not disclose this limitation, The Examiner 
simply ignores it. The rejection of claim 19 should be reversed. 

IV. O. Claim 20 is not anticipated by Shappir. 

Claim 20 depends from claim 19 and is further limited by 
"wherein said result further comprises a JavaScript object". 
Because Shappir does not disclose this limitation, The Examiner 
simply ignores it. The rejection of claim 20 should be reversed. 

V. Claims 14-15 are not obvious over Winter in view of AAPA. 

Claims 14-15 have been rejected under 35 U.S.C. 103(a) as 
unpatentable over Winter in view of Applicant Admitted Prior Art 
(AAPA) . This ground of rejection is respectfully traversed for 
failure of The Examiner to present a prima facie case of 
obviousness . 

To make a prima facie case of obviousness, MPEP 2143 requires 
The Examiner to provide evidence and argument showing: 1) motivation 
to make The alleged combination; 2) reasonable likelihood of success 
of The alleged combination; and 3) all claimed elements within The 
alleged combination. The Examiner has failed to make any of these 
three required showings. Therefore, because The Examiner has not 
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made a prima facie case of obviousness, Applicants need not and 
indeed cannot offer appropriate evidence and argument in rebuttal. 

As to The requirement to show motivation, The Examiner 
concludes: 

It would have been obvious at The time The invention was 
made to a person having ordinary skill in The art to 
modify Winter's system by using The Mapper data base 
management system structure in order to have data base 
management system in an efficient, multi-user environment 
for The stated purpose has been well known in The art a 
evidenced by teaching of AAPA (see first paragraph, page 
2). 

However, Winter has no data base management system at all. 
Furthermore, The Examiner does not allege that it does. Therefore, 
there can be no motivation per se to improve The efficiency of 
Winter's non-existent data base management system by making it The 
claimed MAPPER system. 

The Examiner does not venture any showing of reasonable 
likelihood of success as required by MPEP 2143. However, he could 
not do so, because of The readily apparent incompatibilities of 
AAPA and Winter. 

Finally, The Examiner fails to show all of The claimed 
elements. The claimed "storing means" must be "responsively 
coupled to said requesting means via said publically accessible 
digital data communication network". If The Examiner were to read 
AAPA, he would find The reasons why Mapper could not be so coupled, 
absent Applicants' invention. The rejection of claims 14-15 is 
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respectfully traversed for failure of The Examiner to make any of 
The three showings required by MPEP 2143. 

V.A. Claim 14 is not obvious over Winter in view of AAPA. 

The rejection of claim 14 should be reversed for failure of 
The Examiner to present a prima facie case of obviousness as 
specified by MPEP 2143. 

V.B. Claim 15 is not obvious over Winter in view of AAPA. 

The rejection of claim 15 should be reversed for failure 
of The Examiner to present a prima facie case of obviousness as 
specified by MPEP 2143. 
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CONCLUSION 



Having thus reviewed the final rejections of claims 1-21, 
being all pending claims, it seems abundantly clear that the 
limitations of these claims are not unpatentable in view of the 
prior art of record. Thus, the rejection of these claims should 
be reversed as being based upon clearly erroneous fact findings and 
errors of law. 



Respectfully submitted 



Barbara A. Christensen et al. 



By their attorney, 



Date January /fl 
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Wayne A. Sivertson 
Reg. No. 25,645 
Suite 401, Broadway Place East 
3433 Broadway Street N.E. 
Minneapolis, Minnesota 55413 
(612) 331-1464 
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CLAIMS APPENDIX 



1. An apparatus for processing data upon request comprising: 

a. a legacy data base management system having a first 
command language and having a plurality of datasets; 

b. a user terminal which generates a request in a 
standardized command language for comparing some of said 
plurality of datasets within said legacy data base; 

c. a facility located within said data base management system 
which parses said request in said standardized command 
language into a corresponding request in said first command 
language; and 

d. a result produced by said legacy data base management 
system indicative of honoring said corresponding request. 

2. The apparatus of claim 1 wherein said request in said 
standardized command language further comprises a JavaScript 
object . 

3. The apparatus of claim 2 wherein said result further comprises 
a JavaScript object. 
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4. The apparatus of claim 3 wherein said user session is 
responsively coupled to said data base management system via a 
publically accessible digital data communication network. 

5. The apparatus of claim 4 wherein said data base management 
system further comprises a data base having a plurality of columns 
of data wherein each of said plurality of datasets corresponds to 
a different one of said plurality of columns of data. 

6. A method of comparing a plurality of datasets within The data 
base of a legacy data base management system comprising: 

a. generating a comparison request in a standardized command 
language; 

b. transferring said request to said legacy data base 
management system; 

c. converting said comparison request from said standardized 
command language into a legacy command language suitable 
for execution by said legacy data base management system; 

d. honoring said comparison request; and 

e. sending a result indicative of said honoring step. 

7. A method according to claim 6 wherein said standardized command 
language further comprises a language which is capable of producing 
a JavaScript object. 
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8. A method according to claim 7 wherein said generating step is 
performed by a user terminal. 

9. A method according to claim 8 wherein said result further 
comprises a JavaScript object. 

10. A method according to claim 9 wherein said transferring step 
occurs via a publically accessible digital data communication 
network. 

11. An apparatus for processing data upon request comprising: 

a. storing means for storing a plurality of datasets within a 
legacy data base; 

b. requesting means responsively coupled to said storing means 
for requesting a comparison of said plurality of datasets via 
a standardized command language; 

c. converting means responsively coupled to said storing means 
for converting said standardized command language into a legacy 
command language suitable to access said legacy data base; and 

d. preparing means responsively coupled to said storing means 
for preparing a comparison result. 

12. An apparatus according to claim 11 wherein said standardized 
command language further comprises a language which is capable of 
describing a JavaScript object. 
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13. An apparatus according to claim 12 further comprising a 
publically accessible digital data communication network which 
couples said requesting means to said storing means. 

14. An apparatus according to claim 13 wherein said storing means 
further comprises MAPPER data base management system. 

15. An apparatus according to claim 14 wherein said requesting 
means further comprises an industry standard personal computer. 

16. In a data processing system having a user session which 
generates a request in a standardized command language to compare 
a plurality of datasets responsively coupled to a legacy data base 
management system containing said plurality of datasets, The 
improvement compr i s ing : 

a. a link responsively coupling said user session to said 
legacy data base management system; 

b. a facility which converts said request from said 
standardized command language into a legacy command language 
cognizable by said legacy data base management system; and 

b. a comparison result produced by said legacy data base 
management system from transfer to said user session. 
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17. The improvement according to claim 16 wherein said standardized 
command language further comprises a language which describes a 
JavaScript ob j ect . 

18. The improvement according to claim 17 wherein said link further 
comprises a publically accessible digital data communication 
network. 

19. The improvement according to claim 18 wherein said request 
further comprises a JavaScript object. 

20. The improvement according to claim 19 wherein said result 
further comprises a JavaScript object. 

21. An apparatus for accessing a database comprising: 

a. a legacy data base management system having a first 
command language and having a plurality of datasets; 

b. a user terminal which generates a request as a JavaScript 
standardized command language object for comparing some of 
said plurality of datasets within said legacy data base 
responsively coupled to said legacy data base management 
system via a publically accessible digital data communication 
network; 
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d. a facility which parses said request as said JavaScript 
standardized command language object into a corresponding 
request in said first command language; 

e. a result produced by said legacy data base management 
system indicative of honoring said corresponding request 
converted by said facility to a JavaScript object; and 

f. wherein said legacy data base management system further 
comprises a data base having a plurality of columns of data 
wherein each of said plurality of datasets corresponds to a 
different one of said plurality of columns of data. 
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EVIDENCE APPENDIX 



There is no evidence or documents deemed appropriate 
included within this Appendix. 
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RELATED PROCEEDINGS APPENDIX 



There are no decisions or other papers deemed appropriate 
to be included in this Appendix. 
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